\documentclass{article}

%%%%%%%%%%%%%%%%%% Page Title Here
\newcommand{\TheTitle}{Process Description}
\input{header.tex}

\begin{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Actual Paper Here

\section*{Software Toolset}
\begin{itemize*}
\item Programming languages: Java, JavaScript, PHP, HTML, XML, CSS,
  Clojure, Ruby
\item Data Sources: PostgreSQL
\item Version Control: Google Code/Mercurial
\item Bug tracking: Google Code
\item Framework/Software: Android API, Native Java API, Google Map
  API, Ant, Hudson, Ring/Compojure
\end{itemize*}

We chose the Android platform because the Android API has many
built-in features that make it relatively easy to develop mobile
applications. The Android API includes many libraries such as SQLite
for database and SSL for security. Since Android API is supported
primarily with Java, we will use Java as our primary language along
with XML to program the Android application UI.

Google Map API will be used as an extension to the Android API in
order to provide users routing information. We chose Google Maps
because it has many rich features and could be easily integrated with
our other Android systems.

For the client-side application, we decided to go with a
browser-agnostic web application because it would be cross-platform
compatible. Clients can access the web application through their
laptop or desktop computers. The web application will be implemented
by using a combination of JavaScript, HTML, and CSS as per the web
standard.  Meanwhile, our server will be written in JVM languages so
that we can package everything into a single executable jar for easy
user accessibility.  The main JVM language we will use will be Java
but there will also be substantive amounts of Clojure code to build
the web serving modules.

PostgreSQL will be the back-end to the system for storing information.
We choose PostgreSQL because it is free, open-source, parallel, and
most importantly, has a Java native library, the JDBC.

Lastly, we use Google Code (Mercurial) for version control and bug
tracking because it is free and all of our data will be safely stored
on Google's server which allows team members to have easier
decentralized access to our code without having to worry about data
lost. We will also use Ant to facilitate the building of our overall
release. We will also use Hudson to maintain an automated build so our
tests will be ran every build and we will be alerted if anything
pushed to our repository breaks the building process.

\section*{Group Dynamics}
\begin{itemize*}
\item PM + Tools + Build system + Web Server: Cody
\item Web Platform (HTML/CSS/JS): Trinh
\item Android App: Kevin + Andrew + Jesse
\item Database Handler + Systems Testing + Android App: Andrew
\item Android Socket Server + UI Design + Android App: Jesse
\item Database + DB Interface + Documentation: Chris
\end{itemize*}

We have designated primary roles for each member. Cody was chosen to
be our PM because he has knowledge of many technologies and knows how
to tie it all together. He also does a very good job organizing the
team. His main assigned system module to develop/design is the Web
Server.  His work will then tie in with Trinh's experienced
development of the Web Platform which entails HTML templating, CSS,
and Javascript.  Chris will then be working on the database aspects of
our system because he has formal education in this area. His module
will include database schemas as well as a Java interface to the
actual data. Chris' database interface will then be extended by
Andrew's Database Handler which will be our event-driven core to the
full server and should handle the exchange of consistent information
between the rest of the system and the database itself. The two main
modules that must have this consistency of information is the Web
Server and Jesse's Android Server. The Android Server will be the
communication relay for our actual Android App being developed by
Kevin.

These roles denote the primary responsibility for each module's design
and implementation. However, we understand that isolation will not
always be affordable due to our time constraints so Cody and Andrew,
for instance, will be helping the Android app's development and Jesse
will be helping Chris with his knowledge of databases.  Also, Cody
will be our expert in our software toolset, Jesse will be the resident
UI designer, Andrew will help facilitate whole-system testing, and
Kevin will handle system documentation based on their respective
talents.

This structure was chosen because it allows us to maximize our
resources and maintain highly parallelizable development. We have a
limited amount of time to finish a product that will be put into real
use. As such, we need to place our best people at each area of the
project. We also believe that disagreements should be easily resolved
amongst the team if the need should ever arise.

Disagreements will be brought up to the team and we will do a standard
majority voting unless someone comes up with an overwhelming
argument. In the event of a tie, we will have the PM decide which
option is a better choice or, if possible, make a compromise
facilitated by the PM.

\section*{Schedule/Timeline}
\subsection*{Requirements}
\subsubsection*{Server Team}
\begin{itemize*}
\item Server Setup
\item Server Documentation
\item Database Management
\item Integrated interfaces for web and Android apps
\end{itemize*}
\subsubsection*{Android Team}
\begin{itemize*}
\item UI Creation
\item Module Implementations:
  \begin{itemize*}
  \item Authentication System
  \item Map Routing System (Google Maps)
  \item Data Display
  \item User Alert System
  \item Data Communication with Server
  \end{itemize*}
\end{itemize*}
\subsubsection*{Web-Client Team}
\begin{itemize*}
\item Web Application UI
\item Authentication System
\item Data Entry Form (Adding data to the server)
  \begin{itemize*}
  \item Dynamically updating UI to show changes
  \end{itemize*}
\item Data Retrieval
  \begin{itemize*}
  \item Search System.
  \end{itemize*}
\end{itemize*}

\subsection*{Timeline}
\begin{itemize*}
\item \textbf{Week 1:}
  \begin{itemize*}
  \item Project proposal. (2 Days)
  \item Form team. (4 Days)
  \end{itemize*}
\item \textbf{Week 2:}
  \begin{itemize*}
  \item Meet with customer. (1 Day)
  \item Do initial planning. (1 Day)
  \item Split team into sub-teams. (1 Day)
  \item Assign role(s) to each team member. (1 Day)
  \item Complete Software Requirements Specification. (3 Days)
  \end{itemize*}
\item \textbf{Week 3:}
  \begin{itemize*}
  \item Paper prototyping. (3 Days - Jesse)
  \item Architectural design. (2 Days)
  \item Study APIs that will be used for development. (3 Days - Kevin,
    Trinh, Chris, Cody, Andrew)
  \end{itemize*}
\item \textbf{Week 4:}
  \begin{itemize*}
  \item Complete Software Design Specification. (4 Days)
  \item Setting up repository for code dependencies (3 Days - Cody)
  \item Analyzing customer's feedback on paper prototyping. (1 Day -
    Kevin, Andrew)
  \end{itemize*}
\item \textbf{Week 5:}
  \begin{itemize*}
  \item Milestone: Zero-feature release
    \begin{itemize*}
    \item Setup database. (2 Days - Chris)
    \item Finish basic website element design. (2 Days - Trinh, Cody)
    \item Begin basic Android UI. (4 Days - Kevin)
    \item Partially implementing back-end server applications. (2
      Days - Chris, Andrew, Jesse)
    \end{itemize*}
  \end{itemize*}
\item \textbf{Week 6:}
  \begin{itemize*}
  \item Milestone: Study for Midterm
    \begin{itemize*}
    \item Complete database schema. (1 Day - Chris)
    \item Get web-server operational. (3 Days - Trinh, Cody)
    \item Get Ajax functionality working on website. (2 Days - Trinh)
    \item Setup basic communication between Android application
      and server. (2 Days - Jesse, Kevin)
    \item Implement core features. (5 Days - Team)
    \item Begin documentation. (1 Day) 
    \end{itemize*}
  \end{itemize*}
\item \textbf{Week 7:}
  \begin{itemize*}
  \item Milestone: Beta Release
    \begin{itemize*}
    \item Test Andriod application against server for bugs. (1 Day)
      \begin{itemize*}
      \item Fix Android bugs before demo. (3 Days - Jesse,
        Andrew, Kevin)
      \end{itemize*}
    \item Implement Dynamic Android content, logging in, and viewing
      information given from the server. (2 Days - Kevin, Jesse)
    \item Fix beta release bugs on core features. (3 Days - Chris Cody, Trinh)
    \item Added to core features (1 Day - Chris, Cody, Trinh)
    \item Continue documentation. (2 Days)
    \end{itemize*}
  \end{itemize*}
\item \textbf{Week 8:}
  \begin{itemize*}
  \item Milestone: Beta Demo 
  \item Milestone: Release Candidate
    \begin{itemize*}
    \item Modify database based on new information (2 Days - Chris)
    \item Fix system based on user's feedbacks during the Beta Demo to
      get ready for final Release Candiadate by end of the week. (3
      Days)
    \item Integrated estimated times of arrival (2 Days - Cody)
    \item Add better communication between Android and Server,
      including viewing specimens and routes (5 Days - Jesse, Andrew,
      Kevin)
    \item Finalize documentation for release candidate. (2 Days - Chris)
    \end{itemize*}
  \end{itemize*}
\item \textbf{Week 9:}
  \begin{itemize*}
  \item Milestone: 1.0 Release
    \begin{itemize*}
    \item Add to core features on website (3 Days - Trinh)
    \item Testing of both the web client and Android application.fix
      bugs by the end of the week in order to get ready for 1.0
      Release. (3 Days - Andrew, Jesse, Chris, Kevin, Cody)
    \item Continue debugging before release. (3 Days)
    \item Finalize documentation for final release. (1 Day - Chris)
    \end{itemize*}
  \end{itemize*}
\item \textbf{Week 10:}
  \begin{itemize*}
  \item Milestone: Final Release
    \begin{itemize*}
    \item Ensure Android Application works as expected (2 Days -
      Jesse, Andrew, Kevin)
    \item Modified Documentation about any dropped features (1 Day - Chris)
    \item Ensure Website works as expected (4 Days - Trinh, Cody)
    \item Study for final (3 Days)
    \end{itemize*}
  \end{itemize*}
\end{itemize*}

\section*{Risk}
See SDS under Risk Assessment  for the formal risk documentation.
\\

One major risk associated with this project is that the amount of time
we have remaining to finish the project is very little. Combine this
with the fact that, we have other classes, it is a real risk. Another
major risk is that we are working with unfamiliar hardware. Not many
of us have worked with Android devices or have done with interactions
between a server and a client device so this will be a
challenge. Another risk is that the specifications are not flexible so
we are possibly stuck with being required to complete a difficult
problem which could otherwise be easy if the specifications were bent
a bit.

The risk that worries us the most is the time we have to finish the
project. We know that we can't increase the amount of time and as the
quarter heads toward the end, many of us are feeling the pressure of
not only this class, but others. Overall all the aforementioned
problems are the most serious risks associated with this project.  If
we don't have the time to finish our project, we don't have the
time. We are working with new hardware that we need to learn and
therefore not necessarily may not able to master it. We also have the
problem of not being able to change how an area of the project is done
as it is generally fixed in stone.

There are a few experiments and prototypes that we can execute to our
reduce our developmental risks.  First of all, we can create a
bare-boned web UI that has all graphical elements stubbed and
barely-functional to assess it's usability and learnability.  This
would also allow us to become more proficient at our web development
skills for the final product.  The same thing can be done with the
Android platform as we could create a simple functioning todo-list to
learn the APIs as well as give ourselves a good prototype for our
courier checklist features.

Another way to reduce risk is to have each specialized individual in
our project predict the difficulty of the task at hand. This allows us
to get a measure of how we are allocating our resources. This can be
done by having each member basically attempt to implement the required
features. We will give them a week and by that end of the week, they
will write a report with their progress and if it seems reasonable
that they can finish their part within the allocated time with the
given resources.

If there is a feature we are unable to do, we will most likely do a
feature cut if we can make due without it. However, in the case of the
route finding algorithm, we would still need a algorithm in place to
calculate routes for the couriers so we might default to having a
static route that is calculated relatively easily without any dynamic
rerouting.  So, in the case a major feature needs to be finished, we
will allocate more resources ahead of time by making sure the
difficulty of each area is evaluated weeks in advance.

Feedback will be most useful once we have our UI done for the overall
system.  This will be the most important part because this product
will be used by individuals who will be in contact with it everyday of
their lives. As such, we need to make sure the UI is to their liking
and simple. We will get this feedback most likely by having a meeting
with our customer and using a paper prototype.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%% End Paper Here
\end{document}
